feat: add auth can I operation - #12

Walkthrough

This pull request implements Kubernetes permission checking via a new "authCanI" operation. Changes include adding dependencies, creating a handler and tests for the operation, extending the resource client with SubjectAccessReview-based authorization checks, initializing an authorization client, and registering the operation.

Changes

Sequence Diagram

sequenceDiagram
    participant User as User/Client
    participant Handler as handleAuthCanI
    participant Client as ResourceClient
    participant K8s as Kubernetes API

    User->>Handler: OperationRequest (verb, resource, as, namespace, etc.)
    Handler->>Handler: Validate required parameters
    Handler->>Client: CheckAccess(user, verb, resource, apiGroup, namespace, resourceName)
    Client->>K8s: Create SubjectAccessReview
    K8s-->>Client: SubjectAccessReview result (Allowed, Reason)
    Client-->>Handler: (allowed bool, reason string, error)
    Handler->>Handler: Check against expect (if provided)
    Handler-->>User: OperationResult (Success with allowed/reason outputs)

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related issues

• Add k8s.authCanI operation for checking RBAC permissions #7 — This PR implements the requested k8s.authCanI operation end-to-end, including operation registration, handler implementation, client method, and comprehensive test coverage.

Poem

🐰 Hop-hop, now we check who can do what,
SubjectAccessReviews in each Kubernetes slot!
With verbs and resources and namespaces tight,
Permissions are verified—auth checks done right! ✨

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• 📝 Generate docstrings